"Thorsten Froehlich" <tho### [at] trfde> wrote:
> By the time when cluttering code with unnecessary macros is considered
> better code, I am going to jump out of the window!

By "better quality code" I mean the code that

1) generates less worning messages and thus

2) is less likely to fail.

As to the first point, I consider this a big virtue by itself -- at the very
least helping to spot warnings issued for actually buggy code. I for one
always use a custom POV-Ray compile, with my own additions, and mind you: it
is a real pain dealing with all those 3.5 changes that generate so many
warnings.

As to the second... Thorsten, believe it or not, compiler writers are not
idiots. Not all of them. There ARE cases when simple multi-character
constants would not work, while #defines or similar means would rectify the
situation... For instance, you cannot write a RIFF chunk ID like you do, you
have t use FOURCCs. Well, as far as I can tell (and I know you good enough
by now), at this point you would argue about the "broken format of a broken
OS", and "general inability to provide portable solutions for binary
formats", right? Then consider writing/reading text files:

  unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
  fprintf(outfile," %lu", prog);
  ...
  fscanf(infile," %lu",&prog);
  if( prog==FOURCHARS_TO_INT('A','B','C','D')) { ... }

This code would work ACROSS MOST platforms. While alternative (your)
approach would fail if files are to be transferred between e.g. PCs and old
Macs (with their Motorola 68k BE CPUs). And even if we are to port it to
some EBCDIC-based dinosaur, we still can just modify the macro definition
accordingly, not every piece of code dealing with constants. So the code is
MORE portable and thus BETTER. Please note: not "absolutely portable and
thus the BEST", but still worth trying.

Post a reply to this message